Method, system and apparatus to support hierarchical mobile ip services

ABSTRACT

A basic feature of the invention is to rely on an AAA infrastructure to “bootstrap” the HMIPv6 service for a mobile node ( 130 ) that “roams” in a visited network or the home network. In accordance with a preferred embodiment of the invention, bootstrapping the HMIPv6 service involves authenticating and authorizing the mobile node ( 130 ) for HMIPv6 service based on an AAA infrastructure. In an important scenario, the mobile node is roaming in a visited network, and the AAA infrastructure ( 110, 120, 122 ) links the visited network with the home network of the mobile node. The invention also supports the possibility of having the MAP ( 125 ) located in the home network or other network than the visited network. The reliance on the AAA infrastructure preferably involves transferring HMIPv6-related information required for authenticating and authorizing the mobile node for HMIPv6 service over the AAA infrastructure.

TECHNICAL FIELD OF THE INVENTION

The present invention generally relates to mobile communications, and inparticular to support for Mobile IP (Internet Protocol) services, andespecially Hierarchical Mobile IP version 6 services.

BACKGROUND OF THE INVENTION

Mobile IP (MIP) allows a Mobile Node (MN) to change its point ofattachment to the Internet with minimal service disruption. MIP initself does not provide any specific support for mobility acrossdifferent administrative domains, which limits the applicability of MIPin a large-scale commercial deployment.

The Mobile IP version 6 (MIPv6) protocol [1] allows nodes to move withinthe Internet topology while maintaining reachability and on-goingconnections with correspondent nodes. In this context, each mobile nodeis always identified by its home address, regardless of its currentpoint of attachment to the IPv6 Internet. While situated away from itshome network, a mobile node is also associated with a care-of address(CoA), which provides information about the mobile nodes currentlocation. IPv6 packets addressed to the mobile node's home address aremore or less transparently routed to its care-of address. The MIPv6protocol enables IPv6 nodes to cache the binding of a mobile node's homeaddress with its care-of address, and then send any packets destined forthe mobile node to the care-of address. To this end, the mobile nodesends so-called binding updates to its Home Agent (HA) and thecorrespondent nodes with which it is communicating, every time it moves.Authenticating binding updates requires some round trips between themobile node and each correspondent node. In addition, one round trip isneeded to update the Home Agent, although this can be donesimultaneously while updating correspondent nodes. These round tripdelays will disrupt active connections every time a hand-off to a newaccess router is performed.

For this and other reasons, the Hierarchical Mobile IPv6 (HMIPv6)protocol [2] has been proposed to support local or hierarchical forms ofmobility management. Hierarchical mobility management for Mobile IPv6reduces the amount of signaling between the MN, its Correspondent Nodes(CN), and its HA by introducing a so-called Mobility Anchor Point (MAP)located in the visited network. The introduction of a MAP can also beused to improve the performance of Mobile IPv6 in terms of handoffspeed.

FIG. 1 schematically illustrates an example of a prior art HMIPv6 domainwith a MAP in the visited network. The overall system view includes thehome network 10 with an ordinary Home Agent (HA) 15, the visited network20 with a MAP 25 and access routers (AR) 27. A mobile node (MN) 30entering a MAP domain will receive so-called router advertisementscontaining information on one or more local MAPs. The MN 30 can bind itscurrent location (on-link Care-of Address or LCoA) with an address onthe MAP's subnet called Regional Care-of Address (RCoA). Acting as alocal HA, the MAP 25 will receive all packets on behalf of the MN 30 itis serving and will encapsulate and forward them directly to the MN'sLCoA.

The MAP can help in providing seamless mobility for the mobile node asit moves from Access Router 1 (AR1) 27-1 to Access Router 2 (AR2) 27-2,while communicating with a correspondent node (CN) 40. Upon arrival inthe visited network, the mobile node 30 will discover the global addressof the MAP 25. This address is stored in the access routers andcommunicated to the mobile node via router advertisements. This processis called MAP discovery and is needed to inform mobile nodes of thepresence of the MAP. A MAP domain is normally defined by the accessrouters that advertise the MAP information to attached mobile nodes. Theprocess of MAP discovery continues as the mobile node moves from onesubnet to the next. As long as the mobile roams within a MAP domain, theaccess routers are configured to advertise the same MAP address oraddresses. If a change in the advertised MAP's address is received, themobile node must perform movement detection and send the necessarybinding updates to its Home Agent and correspondent nodes.

If the mobile node is not HMIPv6-aware then no MAP discovery will beperformed and Mobile IPv6 will be used for mobility management. On theother hand, if the mobile node is HMIPv6-aware, it should choose to useHMIPv6. If so, the mobile node registers with a MAP 25 by sending abinding update containing its home address and LCoA address. The homeaddress used in the binding update is the RCoA address, and the MAP 25stores this information in its binding cache to be able to forwardpackets to their final destination when received from the correspondentnodes 40 or HA 15.

HMIPv6 itself, as in the MIP case, does not provide any specific supportfor mobility across different administrative domains, which limits theapplicability of HMIPv6 in a large-scale commercial deployment.

It can normally be expected that the MN would need to be authenticatedfirst before being authorized to use the services of HMIPv6. It isimportant that the security relationship between the mobile node and theMAP is of strong nature; it should preferably involve mutualauthentication, integrity protection and protection against replayattacks. To this end, distribution of credential-related data such assecurity keys between MN and MAP currently has to rely on Public KeyInfrastructures (PKI) and other complex protocols. The current HMIPv6draft [2] also limits the location of the MAP to the visited network.

SUMMARY OF THE INVENTION

The present invention overcomes these and other drawbacks of the priorart arrangements.

It is a general object of the present invention to provide improvedsupport for HMIPv6 service for a mobile node. The solution shouldpreferably include mechanisms that facilitate deployment of HMIPv6.

In particular it is desirable to provide a streamlined, yet robustsolution for authentication and authorization of the HMIPv6 service thatdoes not have to rely on Public Key Infrastructures (PKI) and othercomplex protocols.

It is another object of the invention to enable shortening of theoverall HMIPv6 setup times.

Yet another object of the invention is to provide a method and a systemfor supporting HMIPv6 service.

Still another object of the invention is to provide individual networkcomponents that support streamlined authentication and/or authorizationof the HMIPv6 service.

These and other objects are met by the invention as defined by theaccompanying patent claims.

A basic feature of the invention is to rely on an AAA infrastructure to“bootstrap” the HMIPv6 service for a mobile node. In accordance with apreferred embodiment of the invention, bootstrapping the HMIPv6 serviceinvolves authenticating and authorizing the mobile node for HMIPv6service based on an AAA infrastructure. In an important scenario, themobile node is roaming in a visited network, and the AAA infrastructurelinks the visited network with the home network of the mobile node.However, the invention also supports the scenario when the mobile isactually located in the home network. In this case, an AAAinfrastructure component of the home network may provide the necessarysupport for the HMIPv6 service with a MAP in the home network.

The reliance on the AAA infrastructure preferably involves transferringHMIPv6-related information required for authorizing the mobile node forHMIPv6 service over the AAA infrastructure.

HMIPv6 bootstrapping is normally based on the establishment of asecurity association between an appropriate MAP and the mobile node tosecure pertinent communication, e.g. allowing authenticated HMIPv6 MAPbinding.

In a preferred embodiment of the invention, piggyback of HMIPv6 mobilityprocedures in the same round trip as the HMIPv6 security associationprocedure allows possible shortening of overall setup times byoptimizing authentication, authorization, and mobility in a commonprocedure.

The authorization phase naturally includes explicit authorization butmay also include configuration of the involved nodes. HMIPv6-relatedconfiguration such as configuration of the mobile node and/orconfiguration of the MAP may therefore normally be regarded as part ofthe overall authorization procedure. This typically means that theHMIPv6-related information may be HMIPv6 authentication, authorizationand/or configuration information.

Instead of the conventional MAP discovery process, the AAAinfrastructure is preferably used for assigning an appropriate MAP tothe mobile node, either in response to a MAP assignment requestinitiated from the mobile node (mobile-node-initiated MAP assignment) oras a network-initiated reassignment.

It has also been recognized that there are cases where it would bebeneficial to have the MAP located in the home network or othernetworks, such as for the case where the visited network does notprovide MAP support. A MAP located in the home network can be used toaddress the HA scalability issues, off-loading the HA by reducing thenumber of binding updates that go to the HA during intra-MAP domainmobility. By selecting the MAP to be topographically close to thelocation of the MN, fast handovers can be realized.

In cases when the MAP is located in the home network, it may beappropriate to use the AAA home network server (AAAh) as a suitable AAAinfrastructure component for MAP assignment. On the other hand, when theMAP is located in the visited network it may be appropriate to use theAAA visited network server (AAAv) for MAP assignment. In fact, thelocation of MAP can be in the home network, visited network, or othernetworks. There is no longer any mandatory dependency on the RouterAdvertisements containing information on MAPs within pre-defined MAPdomains.

The reliance on the AAA infrastructure, in contrast to using the PKIinfrastructure, offers different possibilities for bootstrapping theHMIPv6 service. For example, it is possible to provide an extension to ageneral authentication protocol carried over the AAA infrastructureand/or to enhance an AAA framework protocol application.

For example, it has proven to be quite beneficial to transferHMIPv6-related information within an authentication protocol in anend-to-end procedure between the mobile node and an AAA home networkserver. The authentication protocol may be an extended authenticationprotocol based on an existing protocol, or a new protocol.

A possible authentication protocol to be used as a basis forbootstrapping HMIPv6 is the Extensible Authentication Protocol (EAP),creating EAP extensions while preferably keeping the EAP lower layer(s)intact. This normally means that HMIPv6-related information isincorporated as additional data in the EAP protocol stack, for exampleas EAP attributes in the EAP method layer of the EAP protocol stack ortransferred in a generic container on the EAP layer or the EAP methodlayer.

Another way, to be used as a complement or as an alternative to the EAPextensions, would be to enhance the EAP “lower layer(s)” like creating anew or extended AAA framework protocol application such as a Diameterapplication adapted for HMIPv6 or an application based on the Radiusprotocol.

When the MAP is located in the home network, it is for example possibleto use an extended authentication protocol carried over the AAAinfrastructure or an enhanced AAA framework protocol application.However, when the MAP is located in the visited network, an extended EAPprotocol is preferably used in combination with an enhanced AAAframework protocol application, or alternatively the enhanced AAAframework protocol application is used without any support of any EAPextensions.

For example, an extended EAP protocol may be carried by PANA (Protocolfor carrying Authentication for Network Access), PPP (Point-to-PointProtocol), IEEE 802.1X or even over GPRS/UMTS interfaces between themobile node and an AAA client in the visited network, and by a Diameteror Radius application within the AAA infrastructure.

In particular, relying on EAP extensions provides a streamlinedsolution, which is manageable and elegant with a minimum of backwardcompatibility problems. The use of EAP allows the AAA Client (and AAAv)to be agnostic to HMIPv6 procedures (i.e., this removes the dependencyon HMIPv6 support of the visited network), and act as mere pass-throughagent(s), at least when the MAP is located in the home network. This isone of the major advantages of using EAP.

By also including MIPv6-related information in the extendedauthentication protocol stack or in the enhanced AAA framework protocolapplication it is possible to simultaneously accommodate HMIPv6 andMIPv6 authentication and authorization in the same round trip over theAAA infrastructure. It is of course possible to use such anMIPv6/HMIPv6-enabled network and execute only HMIPv6 authenticationand/or authorization without the MIPv6 counterpart, and vice versa,depending on the particular need of the MN at a specific instance. Thisallows a single extended authentication protocol and/or enhanced AAAframework protocol application to be flexibly used on various use casescenarios.

The invention offers the following advantages:

-   -   Efficient bootstrapping of the HMIPv6 service;    -   Efficient transfer of HMIPv6-related information for authorizing        the HMIPv6 service;    -   Streamlined solution for HMIPv6 support based on EAP extension,        which is manageable and elegant with a minimum of backward        compatibility problems;    -   Shortening of the overall HMIPv6 setup times;    -   Optimization of authentication, authorization, and mobility in a        common procedure;    -   AAA-based MAP assignment;    -   MAP-location not limited to visited network;    -   MAP can be located in the home network to address the HA        scalability issues, off-loading the HA by reducing the number of        binding updates that go to the HA during intra-MAP domain        mobility; and    -   Simultaneous accommodation of HMIPv6 and MIPv6 authentication        and authorization in the same round trip.

Other advantages offered by the present invention will be appreciatedupon reading of the below description of the embodiments of theinvention.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention, together with further objects and advantages thereof,will be best understood by reference to the following description takentogether with the accompanying drawings, in which:

FIG. 1 is a schematic diagram illustrating an example of a prior artHMIPv6 domain with the MAP in the visited network;

FIG. 2 is a schematic diagram illustrating a novel architecture forHMIPv6 support for a mobile node roaming in a visited network accordingto an exemplary embodiment of the invention;

FIG. 3 is a schematic diagram illustrating a novel architecture forHMIPv6 support for a mobile node roaming in a visited network accordingto another exemplary embodiment of the invention;

FIG. 4 is a schematic diagram illustrating a novel architecture forHMIPv6 support for a mobile node operating in its own home networkaccording to an exemplary embodiment of the invention;

FIG. 5 is a schematic block diagram of an AAA home network serveraccording to a preferred exemplary embodiment of the invention;

FIG. 6 is a schematic block diagram of a MAP node according to apreferred exemplary embodiment of the invention;

FIG. 7 illustrates an exemplary signaling flow for HMIPv6 AAA usingDiameter/EAP/HMIPv6 for the case when the MAP is located in the homenetwork;

FIG. 8 illustrates an exemplary signaling flow for HMIPv6 AAA usingDiameter/EAP/HMIPv6 in combination with a Diameter HMIPv6 Applicationfor the case when the MAP is located in the visited network;

FIG. 9 illustrates an exemplary signaling flow for HMIPv6 AAA usingDiameter HMIPv6 Application for the case when the MAP is located in thehome network;

FIG. 10 illustrates an exemplary signaling flow for HMIPv6 AAA usingDiameter HMIPv6 Application for the case when the MAP is located in thevisited network; and

FIG. 11 is a schematic flow diagram of an illustrative example of amethod for supporting HMIPv6 service for a mobile node.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

Throughout the drawings, the same reference characters will be used forcorresponding or similar elements.

A basic idea according to the invention is to “bootstrap” the HMIPv6service for a mobile node based on an AAA infrastructure, instead ofrelying on a complex PKI infrastructure for the purpose of HMIPv6authentication and authorization. The HMIPv6 bootstrapping is valid bothfor a mobile node operating in the home network and a mobile noderoaming in a visited network, employing the home network AAAinfrastructure in the former case and the overall AAA infrastructurelinking the visited network with the home network in the latter case.

Instead of establishing a security association and distributing securitykeys between MN and MAP by employing a Public Key Infrastructures (PKI),authentication and authorization of HMIPv6 service is preferablyexecuted based on an AAA infrastructure, for example by transferringHMIPv6-related information required for authenticating and authorizingthe mobile node for HMIPv6 service over the AAA infrastructure.

Instead of the conventional MAP discovery process, the AAAinfrastructure is preferably also used for assigning an appropriate MAPto the mobile node, either in response to a MAP assignment requestinitiated from the mobile node (mobile-node-initiated MAP assignment) oras a network-initiated reassignment, as will be described in more detaillater on. There is no longer any mandatory dependency on the RouterAdvertisements containing information on MAPs within pre-defined MAPdomains.

The AAA HMIPv6 bootstrapping is normally based on the establishment of asecurity association, i.e. a security relation, between an appropriateMAP and the mobile node over the AAA infrastructure to secure pertinentcommunication, e.g. allowing authenticated HMIPv6 MAP binding.

In a preferred implementation, HMIPv6 mobility procedures includingbinding updates are piggybacked in the same round trip as the HMIPv6security association procedure, thereby allowing possible shortening ofoverall setup times by optimizing authentication, authorization, andmobility in a common procedure.

The term “AAA” should be taken within its general meaning of Internetdrafts, RFCs and other standardization documents. Typically, theauthentication and security key agreement of an AAA (Authorization,Authentication, Accounting) infrastructure is based on symmetriccryptography, implying the existence of an initial secret shared betweenthe mobile node and the home network operator or a trusted party. Insome scenarios and applications, for example the accounting feature ofthe AAA infrastructure may be disabled or not implemented. The AAAinfrastructure generally includes one or more AAA servers, in the homenetwork, intermediate networks (if any) and/or the visited network, andmay also include one or more AAA clients.

In general, AAA protocols such as the Diameter protocol precisely enablemobile users to roam and obtain service in networks that may notnecessarily be owned by their home service provider. For Mobile IP to bedeployed in commercial networks, there therefore has to be AAA supportfor the protocol. For the special case of Mobile IPv6 (MIPv6) withoutany hierarchical mobility management, an Internet draft [3] has beenproposed which specifies a new application to Diameter that enablesMIPv6 roaming in networks other than the network administered by thehome operator. In our U.S. Provisional Patent Application 60/479,156filed Jun. 18, 2003 and also in the later Internet draft [4] anarchitecture and related protocols for performing Mobile IPv6authorization and configuration based on an AAA infrastructure aresuggested. The necessary interaction between the AAA server of the homeprovider and the mobile node for MIPv6 is realized using EAP (ExtensibleAuthentication Protocol), which convey information for Mobile IPv6negotiation together with authentication data.

FIG. 2 is a schematic diagram illustrating a novel architecture forHMIPv6 support according to an exemplary embodiment of the invention.The mobile node 130 is roaming in a visited network, and HMIPv6authentication and authorization is performed by using an AAAinfrastructure linking the visited network and the home network of themobile node. In this example, the AAA infrastructure basically involvesan AAA home network server 110, an AAA visited network server 120 and anAAA client 122 in the visited network.

Preferably, the AAA visited network server (AAAv) 120 can be used as asuitable AAA infrastructure component for MAP assignment, taking thevisited operator's policy into account in the selection of MAP. The MAPselection could be for example based the current load of the availableMAPs, the location of the mobile node and/or possibly preferences givenby the mobile node.

A main component of the AAA infrastructure is the AAAh server 110, whichpreferably forwards any request for MAP assignment from a mobile node tothe AAAv server 120, and furthermore generates a security key or similarcredentials for immediate or future security association between a givenmobile node 130 and an assigned MAP 125. The security key is thentypically transferred from the AAAh 110 to the MAP 125 via the AAAv 120,and the MAP 125 preferably responds with information for finalizing thesecurity association to the AAAh 110 via the AAAv 120. Finally, the AAAhserver 110 sends the generated and collected HMIPv6 authorizationinformation to the mobile node 130 over the AAA infrastructure. It isassumed that secure tunnels of the AAA infrastructure or other securitymeasures such as encryption and source integrity protection are employedfor transfer of sensitive information such as the security key(s).

The reliance on the AAA infrastructure offers different possibilitiesfor bootstrapping the HMIPv6 service. For example, it is possible toprovide a new authentication protocol, or to provide an extension to anauthentication protocol carried over the AAA infrastructure and/or toenhance an AAA framework protocol application to carry theHMIPv6-related information, as schematically indicated in FIG. 2.

Preferably, an extended authentication protocol such as an extended EAP(Extensible Authentication Protocol) protocol adapted for HMIPv6 isutilized, with the addition of an enhanced AAA framework protocolapplication such as a HMIPv6 Diameter or Radius Application for theinterface between AAAh server and the visited network MAP via the AAAvserver.

For example, a new or extended authentication protocol may be carried byPANA (Protocol for carrying Authentication for Network Access), PPP(Point-to-Point Protocol), IEEE 802.1X or even over GPRS/UMTS interfacesbetween the mobile node and the AAA client in the visited network, andby Diameter or similar AAA framework or carrier protocol within the AAAinfrastructure.

Alternatively, an enhanced AAA framework protocol application such as anew or extended Diameter or Radius Application is used without thesupport of any EAP extensions. For the path between the mobile and theAAA client, the Diameter or Radius Application could for example becarried by ICMP (Internet Control Message Protocol).

It has also been recognized that there are cases where it would bebeneficial to have the MAP located in the home network or othernetworks, such as for the case where the visited network does notprovide MAP support. An exemplary architecture for HMIPv6 support withMAP located in the home network is illustrated in FIG. 3.

It is here beneficial to use the AAA home network server (AAAh) 110 forMAP assignment. Preferably, the AAA home network server (AAAh) 110 alsogenerates a security key or similar security parameters or credentialsfor security association between the mobile node and the assigned MAP125 and sends said security key to the MAP 125. The MAP 125 respondswith information for finalizing the security association to the AAAh110, and the AAAh 110 subsequently sends HMIPv6 authorizationinformation to the mobile node 130 over the AAA infrastructure.

Since the MAP 125 is located in the home network, the AAAv 120 does nothave to see the transaction, and it is thus possible to have an“end-to-end procedure” for HMIPv6 authentication and authorization. Thisis preferably accomplished by using an extended authentication protocolsuch as an extended EAP (Extensible Authentication Protocol) protocoladapted for HMIPv6. Alternatively, an enhanced AAA framework protocolapplication such as a HMIPv6 Diameter or Radius Application can beutilized. A MAP 125 located in the home network can also be used toaddress the HA scalability issues, off-loading the HA 115 by reducingthe number of binding updates that go to the HA 115 during intra-MAPdomain mobility. By selecting the MAP to be topographically close to thelocation of the MN, fast handovers can be realized.

As should be understood, the invention has removed the limitation of theprior art that the MAP 125 has to be located in the visited network.Now, the location of the MAP can be in the home network, visitednetwork, or other networks. Technically, it would be possible for the MNto bind with any MAP as long as an RCoA on the MAP can be obtained withAAA support, if operators allow this.

Re-assignment of MAP may occur during the following exemplary cases:

-   -   Expiration of security keys between MN and MAP—for this case,        the MN initiates HMIPv6 re-authentication/authorization, and the        network may assign a different MAP that is more appropriate        based on, e.g., current topological location of MN.    -   At the request of mobile node (MN initiated)—for this case, the        MN initiates HMIPv6 re-authentication/authorization requesting        re-assignment of MAP    -   At the request of the network (network initiated)—for the case,        either the AAAh or AAAv initiates the re-assignment of MAP and        “pushes” this to the MN when the need arises, e.g., when the MN        moves to an AR that is better covered by a new MAP.

With reference to FIGS. 2 and 3 again, a number of possible examples ofdifferent protocol combinations between the segments AAA Client—AAAh,and AAAh—(AAAv)—MAP are summarized below: AAA Client <-> AAAh AAAh <->(AAAv) <-> MAP   (i) AAA HMIPv6 Application AAA HMIPv6 Application  (ii)Extended Authentication Protocol AAA HMIPv6 Application (iii) ExtendedAuthentication Protocol Extended Authentication Protocol

The combination (iii) is especially applicable for the case where theMAP is located in the home network. When the MAP is located in thevisited network, the AAAv may be involved in the selection of MAP basedon visited network policy.

In another scenario, illustrated schematically in FIG. 4, the mobilenode 130 is actually located in the home network and an AAAinfrastructure component of the home network such as the AAAh server 110provides the necessary support for the HMIPv6 service with a MAP 125 inthe home network. This means that only the relevant portions of theextended authentication HMIPv6 protocol and AAA HMIPv6 application haveto be used for exchange of the necessary authentication andauthorization information.

FIG. 5 is a schematic block diagram of an AAA home network serveraccording to a preferred exemplary embodiment of the invention. In thisexample, the AAAh server 110 basically comprises an optional MAPassignment module 111, a security association module 112, anauthorization information manager 113 and an input-output (I/O)interface 114. For the MAP in the home network case, the AAAh server 110includes the MAP assignment module 111, which is operable for assigningand/or re-assigning a suitable MAP to the mobile node. For the MAP inthe visited network case, the AAAh server 110 typically receives thenecessary MAP assignment information on its I/O-interface 114. The AAAhserver typically also receives a key seed and a binding update (BU) fromthe mobile node. Alternatively, the AAAh server generates the key seeditself and sends it to the mobile node. The security association module112 preferably generates the required security key in response to theseed, and securely transfers this key to the MAP (directly to a MAP inthe home network or via the AAAv server to a MAP in the visitednetwork). The binding update (BU) is also forwarded to the MAP. The AAAhserver 110 receives an RCoA address from the MAP and stores this dataalong with other relevant authorization (and/or configuration)information in the authorization information manager 113. The AAAhserver may also receive information, such as IPSec information, from theMAP for finalizing the security association. Finally, the collectedauthorization (and/or configuration) information is transferred to themobile node.

The AAAh server may also be responsible for home address assignment(unless the home address is configured by the MN itself) and/or homeagent assignment.

FIG. 6 is a schematic block diagram of a MAP node according to apreferred exemplary embodiment of the invention. In this example, theMAP 125 basically comprises an RCoA assignment module 126, a securityassociation module 127 and an input-output (I/O) interface 128. The MAPpreferably interacts with the AAA home network server for supporting theestablishment of a security association with the mobile node. The MAPreceives a security key from the AAA home network server over the I/Ointerface 128 for secure storage in the security association module 127.The MAP also prepares and sends information necessary for finalizing thesecurity association with the mobile back to the AAA home networkserver, which in turn forwards the information to the mobile node overthe AAA infrastructure. For binding in the MAP, the RCoA module 126preferably assigns an RCoA address to the mobile node, stores thisaddress together with the LCoA address of the mobile node in the bindingcache (not shown) of the MAP, and also sends the assigned RCoA addressto the AAA home network server for subsequent forwarding to the mobilenode.

For a better understanding of the invention, somewhat more detailedexamples of an extended authentication protocol for HMIPv6 and an AAAframework protocol application adapted for HMIPv6 will now be described.

Extended Authentication Protocol for HMIPv6

In a preferred exemplary embodiment, an extended authentication protocolfor HMIPv6, here exemplified by a new or extended EAP authenticationprotocol (referred to as “HMIPv6 authentication method” or“EAP/HMIPv6”), is defined that carries HMIPv6 related informationfacilitating for example discovery of MAP, dynamic allocation of MAP,dynamic allocation of RCoA, distribution of security key(s) between MNand MAP, and/or possible piggyback of HMIPv6 mobility procedures.

If desired, both HMIPv6 and MIPv6 authentication and/or authorizationcan be integrated in the same protocol, e.g. defining EAP/HMIPv6 as asuperset of a EAP/MIPv6 protocol, which in addition to MIPv6-specificType-Length-Values (TLVs) also defines new HMIP-specific TLV attributes.By including EAP/MIPv6 TLV attributes as part of EAP/HMIPv6, it will bepossible to accommodate simultaneous executions of both MIPv6 and HMIPv6authentication and/or authorization in a single traversal which enablesshorter setup times. It would also be possible to execute only HMIPv6authentication and/or authorization without the MIPv6 counterpart andvice versa, depending on the particular need of the MN at a specificinstance. This allows a single EAP authentication protocol, EAP/HMIPv6,to be flexibly used on various use case scenarios.

In particular, relying on EAP extensions provides a streamlinedsolution, which is manageable and elegant with a minimum of backwardcompatibility problems. The use of EAP allows the AAA Client (and AAAv)to be agnostic to HMIPv6 procedures (i.e., this removes the dependencyon HMIPv6 support of the visited network), and act as mere pass-throughagent(s), at least when the MAP is located in the home network. This isone of the major advantages of using EAP.

As previously indicated, EAP/HMIPv6 may for example be carried by PANA,PPP, ICMP, IEEE 802.1X or even over GPRS/UMTS interfaces between themobile node and the AAA client in the visited network. Although, PANAmay be preferred in some cases, other carrier protocols which satisfyEAP requirements on lower layer ordering guarantees such as PPP [6] andIEEE 802.1X [7] may be used to carry EAP/HMIPv6 between the MN and AAAClient. Specifically for the 3GPP2 CDMA2000 case, it is possible tocarry EAP/HMIPv6 between the MN and AAA Client using PPP Data Link Layerprotocol encapsulation with protocol field value set to C227 (Hex) forEAP [6].

A preferred embodiment uses Diameter, Radius or similar AAA framework orcarrier protocol for communication between the AAA client and the AAAhserver. For example, beyond the AAA client towards and within the AAAinfrastructure, Diameter EAP Application [5] may be used to encapsulateEAP/HMIPv6 within Diameter, i.e. between the PAA/AAA Client and AAAh.The Diameter protocol may also be used by AAAh for optional assignmentof MIP packet filters via MIP filter rules to the PAA/EP and HA, whichcorrespond to the filter enforcement points. The Diameter protocol mayalso be used by AAAh for distribution of security keys to PAA for PANAsecurity, and optional signaling of QoS parameters.

It should be noted that even though Diameter is the preferred choice, itmay sometimes be appropriate to instead use another AAA protocol, suchas Radius, with modifications obvious to the man skilled in the art.

Furthermore, piggyback of HMIPv6 mobility procedures in EAP/HMIPv6 allowpossible shortening of overall setup times by optimizing authentication,authorization, and mobility in a common procedure.

Exemplary EAP/HMIPv6 Protocol Details

In the following, exemplary EAP/HMIPv6 protocol details are provided toshow examples of the overall flow and viability of concept.

EAP TLV Attributes

In a first realization example, a set of new EAP TLV attributes isdefined under EAP/HMIPv6. By means of these attributes, the EAP protocolcan, in addition to the main IPv6 authentication information, carryHMIPv6-related information and optionally also MIPv6-relatedinformation:

Different authentication protocols are possible for EAP/HMIPv6. In apreferred embodiment, the invention proposes implementation throughMD5-challenge authentication, but other protocols also lie within thescope of the invention.

An exemplary summary matrix of EAP/HMIPv6 TLV's is given below in TableI: EAP/HMIPv6 Type-Length-Values Source Destination Purpose CommentHMIPv6 specific TLV's: RCoA Request EAP-TLV attribute MN AAAh requestRCoA RCoA Response EAP-TLV attribute AAAh MN assign RCoA MAP in homeAAAh MN forward RCoA from AAAv MAP in visited RCoA EAP-TLV attributeAAAh MAP assign RCoA MAP in home MAP Address Request EAP-TLV attributeMN AAAh request MAP address MAP Address Response EAP-TLV attribute AAAhMN assign MAP address MAP in home AAAh MN forward MAP address from AAAvMAP in visited MAP-MN Pre-shared Key Generation Nonce EAP-TLV attributeMN AAAh seed for MN-MAP key MAP-MN Pre-shared Key EAP-TLV attribute AAAhMAP assign MN-MAP key MAP in home MAP IKE KeyID EAP-TLV attribute AAAhMN assign IKE KeyID MAP in home MAP-MN IPSec SPI EAP-TLV attribute MAPMN via AAAh assign SPI MAP in home AAAh MN forward from MAP MAP invisited MAP-MN IPSec Protocol EAP-TLV attribute MAP MN via AAAh assignIPSec Protocol MAP in home AAAh MN forward from MAP MAP in visitedMAP-MN IPSec Crypto EAP-TLV attribute MAP MN via AAAh assign IPSecCrypto MAP in home AAAh MN forward from MAP MAP in visited MAP-MN IPSecKey Lifetime EAP-TLV attribute MAP MN via AAAh assign IPSec Key LifetimeMAP in home AAAh MN forward from MAP MAP in visited HMIP-Binding-UpdateEAP-TLV attribute MN MAP via AAAh piggyback HMIP binding update MAP inhome MN AAAh piggyback HMIP binding update MAP in visitedHMIP-Binding-Acknowledgement EAP-TLV attribute MAP MN via AAAh piggybackHMIP binding ack. MAP in home AAAh MN forward from MAP MAP in visitedMIPv6 specific TLV's (optional): MIPv6 Home Address EAP-TLV attributeAAAh HA assign MN Home Address HA-MN Pre-shared Key EAP-TLV attributeAAAh HA assign HA-MN key HA-MN IPSec Protocol EAP-TLV attribute HA MNvia AAAh assign IPSec Protocol HA-MN IPSec Crypto EAP-TLV attribute HAMN via AAAh assign IPSec Crypto MIP-Binding-Update EAP-TLV attribute MNHA via AAAh piggyback MIP binding update MIP-Binding-AcknowledgementEAP-TLV attribute HA MN via AAAh piggyback MIP binding ack. Basic MIPv6TLV's (optional): MD5 Challenge EAP-TLV attribute AAAh MN issuechallenge MD5 Response EAP-TLV attribute MN AAAh provide response tochallenge MIPv6 Home Address Request EAP-TLV attribute MN AAAh requestMN home address MIPv6 Home Address Response EAP-TLV attribute AAAh MNassign MN home address MIPv6 Home Agent Address Request EAP-TLVattribute MN AAAh request HA address MIPv6 Home Agent Address ResponseEAP-TLV attribute AAAh MN assign HA address HA-MN Pre-shared KeyGeneration Nonce EAP-TLV attribute MN AAAh seed for HA-MN key IKE KeyIDEAP-TLV attribute AAAh MN info for obtaining HA-MN pre-shared key fromAAAh HA-MN IPSec SPI EAP-TLV attribute HA MN via AAAh assign SPI HA-MNIPSec Key Lifetime EAP-TLV attribute HA MN via AAAh assign IP Sec Keylifetime PAC-PAA Pre-shared Key Generation Nonce EAP-TLV attribute MNAAAh seed for PAC-PAA keyNote:the IKE KeyID includes some octets which informs the HA/MAP how toretrieve (or generate) the HA-MN pre-shared key/MAP-MN pre-shared keyfrom AAAh.

One or more of the following exemplary EAP-TLV attributes may be definedfor HMIPv6 purposes:

RCoA Request EAP-TLV Attribute:

This represents a request for a dynamically allocated RCoA address forthe authenticated MN. It will be requested by the MN to the AAAh whenthe MN requests to be authenticated and given HMIPv6 service.

RCoA Response EAP-TLV Attribute:

This represents a dynamic allocated RCoA address for the authenticatedMN. It will be notified to the MN from AAAh when the MN, which hasrequested for one, has been successfully authenticated.

RCoA EAP-TLV Attribute:

This represents a dynamic allocated RCoA address for the authenticatedMN. It will be notified to the MAP from AAAh in order to assign the RCoAaddress in the MAP, when the MN, which has requested for one, has beensuccessfully authenticated.

MAP Address Request EAP-TLV Attribute:

This represents a request for an address of a dynamically allocated MAPfor the MN when successfully authenticated. It will be requested by theMN to the AAAh when a MN requests to be authenticated and given HMIPv6service. As the HMIPv6 protocol has a dynamic MAP discovery method toallocate the MAP, this attribute is optional.

MAP Address Response EAP-TLV Attribute:

This represents an address of a dynamic allocated MAP for theauthenticated MN. It will be notified to the MN from the AAAh when a MNrequests to be authenticated and given HMIPv6 service. As the HMIPv6protocol has a dynamic MAP discovery method to allocate the MAP, thisattribute is optional.

MAP-MN Pre-Shared Key Generation Nonce EAP-TLV Attribute:

This represents the octet string generated randomly by MN as a seed forgenerating the pre-shared key between MAP-MN. The MN can internallygenerate the MAP-MN pre-shared key by using an appropriate hashalgorithm on the combination of this nonce and the shared key between MNand AAAh. This attribute is optional when a valid MAP-MN pre-shared keyalready exists.

MAP-MN Pre-Shared Key EAP-TLV Attribute:

This represents a dynamically generated pre-shared key between MAP-MN.It will be notified to the MAP from the AAAh when a MN requests to beauthenticated and given HMIPv6 service. The AAAh can internally generatethe MAP-MN pre-shared key by using an appropriate hash algorithm on thecombination of the nonce given by the MAP-MN Pre-shared Key GenerationNonce EAP-TLV Attribute and the shared key between MN and AAAh. Thisattribute is optional when a valid MAP-MN pre-shared key already exists.

MAP IKE Key ID EAP-TLV Attribute:

This represents the ID payload defined in [8]. The KeyID is generated bythe AAAh and sent to the MN upon successful authentication. The KeyIDincludes some octets which informs the MAP how to retrieve (or generate)the MAP-MN pre-shared key from AAAh. This attribute is optional, andwould generally not be needed when the MN did not submit a MAP-MNpre-shared key generation nonce, i.e., a valid MAP-MN pre-shared keyalready exists, e.g., during MIPv6 handoffs. It is also not needed forthe case when the MAP-MN pre-shared key is conveyed by the AAAh to theMAP.

MAP-MN IPSec SPI EAP-TLV Attribute:

This represents the Security Parameter Index for IPSec between MAP-MN.This is preferably generated by the MAP and informed to the MN for thecase when the MAP-MN pre-shared key is conveyed by the AAAh to the MAP.This attribute is optional and is generally not needed when the MN didnot submit a MAP-MN pre-shared key generation nonce, i.e. a valid MAP-MNpre-shared key already exists, e.g., during MIPv6 handoffs.

MAP-MN IPSec Protocol EAP-TLV Attribute:

This represents the IPSec Protocol (e.g. ESP or AH) between MAP-MN. Thisis informed to the MN for the case when the MAP-MN pre-shared key isconveyed by the AAAh to the MAP. This attribute is optional and isgenerally not needed when the MN did not submit a MAP-MN pre-shared keygeneration nonce, i.e. a valid MAP-MN pre-shared key already exists,e.g., during MIPv6 handoffs.

MAP-MN IPSec Crypto EAP-TLV Attribute:

This represents the Cryptographic Algorithm for IPSec between MAP-MN.This is informed to the MN for the case when the MAP-MN pre-shared keyis conveyed by the AAAh to the MAP. This attribute is optional and isgenerally not needed when the MN did not submit a MAP-MN pre-shared keygeneration nonce, i.e. a valid MAP-MN pre-shared key already exists,e.g., during MIPv6 handoffs.

MAP-MN IPSec Key Lifetime EAP-TLV Attribute:

This represents the Key Lifetime for IPSec between MAP-MN. This isinformed to the MN for the case when the MAP-MN pre-shared key isconveyed by the AAAh to the MAP. This attribute is optional and isgenerally not needed when the MN did not submit a MAP-MN pre-shared keygeneration nonce, i.e. a valid MAP-MN pre-shared key already exists,e.g., during MIPv6 handoffs.

HMIP-Binding-Update EAP-TLV Attribute:

This represents the MAP Binding Update packet generated by the MN. Thisis forwarded to the MAP via AAAh from the MN in the authentication andauthorization exchanges. This attribute is optional and is generally notneeded when the MN sends MAP Binding Update packet directly to MAP.

HMIP-Binding-Acknowledgement EAP-TLV Attribute:

This represents the MAP Binding Acknowledgement packet generated by theMAP. This is forwarded to the MN via AAAh from the MAP in theauthentication and authorization exchanges. This attribute is optionaland is generally not needed when the MAP sends MAP Binding Update packetdirectly to MN.

The following optional EAP-TLV attributes may be defined for specialMIPv6 purposes:

MIPv6 Home Address EAP-TLV Attribute:

This represents a dynamic allocated MIPv6 home address for theauthenticated MN. It will be notified to the HA from AAAh in order toassign the MIPv6 home address in the HA, when the MN, which hasrequested for one, has been successfully authenticated.

HA-MN Pre-Shared Key EAP-TLV Attribute:

This represents a dynamically generated pre-shared key between HA-MN. Itwill be notified to the HA from the AAAh when a MN requests to beauthenticated and given MIPv6 service. The AAAh can internally generatethe HA-MN pre-shared key by using an appropriate hash algorithm on thecombination of the nonce given by the HA-MN Pre-shared Key GenerationNonce EAP-TLV Attribute and the shared key between MN and AAAh. Thisattribute is optional when a valid HA-MN pre-shared key already exists.

HA-MN IPSec Protocol EAP-TLV Attribute:

This represents the IPSec Protocol (e.g. ESP or AH) between HA-MN. Thisis informed to the MN for the case when the HA-MN pre-shared key isconveyed by the AAAh to the HA. This attribute is optional and isgenerally not needed when the MN did not submit a HA-MN pre-shared keygeneration nonce, i.e., a valid HA-MN pre-shared key already exists,e.g., during MIPv6 handoffs.

HA-MN IPSec Crypto EAP-TLV Attribute:

This represents the Cryptographic Algorithm for IPSec between HA-MN.This is informed to the MN for the case when the HA-MN pre-shared key isconveyed by the AAAh to the HA. This attribute is optional and isgenerally not needed when the MN did not submit a HA-MN pre-shared keygeneration nonce, i.e., a valid HA-MN pre-shared key already exists,e.g., during MIPv6 handoffs.

MIP-Binding-Update EAP-TLV Attribute:

This represents the Binding Update packet generated by the MN. This isforwarded to the HA via AAAh from the MN in the authentication andauthorization exchanges. This attribute is optional and is generally notneeded when the MN sends Binding Update packet directly to HA.

MIP-Binding-Acknowledgement EAP-TLV Attribute:

This represents the Binding Acknowledgement packet generated by the HA.This is forwarded to the MN via AAAh from the HA in the authenticationand authorization exchanges. This attribute is optional and is generallynot needed when the HA sends the Binding Acknowledgement packet directlyto MN.

The following EAP-TLV attributes may be defined for HMIPv6/MIPv6authentication:

MD5 Challenge EAP-TLV Attribute:

This represents the octet string generated randomly by the AAAh and sentto MN for MD5 challenge.

MD5 Response EAP-TLV Attribute:

This represents the octet string generated as a result of MD5 hashfunction with the shared secret key between AAAh and MN.

The following optional EAP-TLV attributes may be defined for dynamic MNhome address allocation:

MIPv6 Home Address Request EAP-TLV Attribute:

This represents a request for a dynamically allocated MIPv6 home addressfor the authenticated MN. It will be requested by the MN to the AAAhwhen the MN initially requests to be authenticated and given MIPv6service. This attribute is optional when the MN already has a previouslyassigned home address, e.g., during MIPv6 handoffs.

MIPv6 Home Address Response EAP-TLV Attribute:

This represents a dynamic allocated MIPv6 home address for theauthenticated MN. It will be notified to the MN from AAAh when the MN,which has requested for one, has been successfully authenticated. Thisattribute is optional when the MN already has a previously assigned homeaddress, e.g., during MIPv6 handoffs.

The following optional EAP-TLV attributes may be defined for dynamic HAallocation:

MIPv6 Home Agent Address Request EAP-TLV Attribute:

This represents a request for an address of a dynamically allocated HAfor the MN when successfully authenticated. It will be requested by theMN to the AAAh when a MN initially requests to be authenticated andgiven MIPv6 service. As the MIPv6 protocol has a dynamic HA discoverymethod to allocate the HA, this attribute is optional. This is also thecase when the MN already has a previously assigned HA, e.g., duringMIPv6 handoffs.

MIPv6 Home Agent Address Response EAP-TLV Attribute:

This represents an address of a dynamic allocated HA for theauthenticated MN. It will be notified to the MN from the AAAh when a MNinitially requests to be authenticated and given MIPv6 service. As theMIPv6 protocol has a dynamic home agent discovery method to allocate thehome agent, this attribute is optional. This is also the case when theMN already has a previously assigned HA, e.g., during MIPv6 handoffs.

The following optional EAP-TLV attributes may be defined fordistribution of security keys between HA and MN:

HA-MN Pre-Shared Key Generation Nonce EAP-TLV Attribute:

This represents the octet string generated randomly by MN as a seed forgenerating the pre-shared key between HA-MN. The MN can internallygenerate the HA-MN pre-shared key by using an appropriate hash algorithmon the combination of this nonce and the shared key between MN and AAAh.This attribute is optional when a valid HA-MN pre-shared key alreadyexists, e.g., during MIPv6 handoffs.

IKE KeyID EAP-TLV Attribute:

This represents the ID payload defined in [8]. The KeyID is generated bythe AAAh and sent to the MN upon successful authentication. The KeyIDincludes some octets which informs the HA how to retrieve (or generate)the HA-MN pre-shared key from AAAh. This attribute is optional, andwould generally not be needed when the MN did not submit a HA-MNpre-shared key generation nonce, i.e., a valid HA-MN pre-shared keyalready exists, e.g., during MIPv6 handoffs. It is also not needed forthe case when the HA-MN pre-shared key is conveyed by the AAAh to the HAvia the AAAh-HA interface defined in [9].

HA-MN IPSec SPI EAP-TLV Attribute:

This represents the Security Parameter Index for IPSec between the HAand MN. This is generated by the HA and informed to the MN for the casewhen the HA-MN pre-shared key is conveyed by the AAAh to the HA via theAAAh-HA interface defined in [9]. This attribute is optional and isgenerally not needed when the MN did not submit a HA-MN pre-shared keygeneration nonce, i.e., a valid HA-MN pre-shared key already exists,e.g., during MIPv6 handoffs. It is also not needed for the case when theAAAh-HA interface defined in [9] is not used.

HA-MN IPSec Key Lifetime EAP-TLV Attribute:

This represents the Key Lifetime for IPSec between the HA and MN. Thisis generated by the HA and informed to the MN for the case when theHA-MN pre-shared key is conveyed by the AAAh to the HA via the AAAh-HAinterface defined in [9]. This attribute is optional and is generallynot needed when the MN did not submit a HA-MN pre-shared key generationnonce, i.e., a valid HA-MN pre-shared key already exists, e.g. duringMIPv6 handoffs. It is also not needed for the case when the AAAh-HAinterface defined in [9] is not used.

Finally, the following optional EAP-TLV attribute may be defined fordistribution of security keys between PAC and PAA for PANA security:

PAC-PAA Pre-Shared Key Generation Nonce EAP-TLV Attribute:

This represents the octet string generated randomly by MN/PAC as a seedfor generating the pre-shared key between PAC-PAA. The MN/PAC caninternally generate the PAC-PAA pre-shared key by using an appropriatehash algorithm on the combination of this nonce and the shared keybetween MN and AAAh. This attribute is needed for PANA security.

Alternatively, the AAAh server may be configured for generating not onlythe MN-MAP security key but also the information required for finalizingthe security association.

As can be seen from the above examples, the HMIPv6-related configurationis normally regarded as part of the overall authorization procedure.

EAP Generic Container Attribute (EAP GCA)

In an alternative EAP realization, EAP is used as a carrier ofHMIPv6-related information (optionally also MIPv6 information) withoutcreating a new so-called EAP method, but rather by carrying theinformation in a generic container EAP attribute that can be usedtogether with any EAP method.

In this exemplary realization, which builds on AAA support in the accessnetwork, EAP is augmented with a generic container attribute that can beused to carry any (assumedly non-EAP related) data, e.g. HMIPv6-specificdata and optionally also MIPv6-specific data (if MIPv6 bootstrapping isalso desired). This allows the MN and the AAAh to communicate in amanner that is transparent to the visited domain, including the accessnetwork, the AAA client and the AAAv, at least for the MAP in the homenetwork case. EAP is preferably carried in a AAA protocol, e.g. theDiameter EAP Application or even RADIUS [10], [11], between the AAAclient and the AAAh.

This new attribute should preferably be available for all EAP methodsand can be included in any EAP message, including EAP Success/Failuremessages. In this solution the new generic container attribute is usedto convey HMIPv6-specific data (optionally also MIPv6 data) between theMN and the AAAh. The solution may also include a Diameter or RADIUSapplication that is used to exchange AAA and relevant data between theAAAh and the HA.

In the following, a possible implementation of a generic containerattribute (GCA) is discussed in terms of the current EAP protocol [12].As stated, the generic container attribute should preferably beavailable to all methods and should be possible to include in any EAPmessage, including EAP Success/Failure messages. This implies that itshould be a part of the EAP layer rather than the EAP method layer [12].An important issue to consider is backward compatibility¹. The use ofthe GCA in the given examples normally assumes that the new attribute isintroduced in EAP in a manner that is backward compatible andtransparent to the EAP authenticator. Introducing a GCA with theseproperties may require some special considerations, as will be discussedbelow.¹ This refers to backward compatibility in terms of the MN and the EAPauthenticator (typically located in the NAS). The MN and the EAPauthentication server (i.e. the AAAh) are assumed to always becompatible.

For example, the format of the GCA could be a two-byte GCA lengthindicator followed by a GCA recipient indicator and a GCA payload. TheGCA recipient indicator would indicate to what internal entity the EAPmodule should send the payload of the received GCA (i.e. this indicatorwould correspond to the protocol/next header field in the IP header orthe port number in the UDP and TCP headers). The GCA payload would thenbe a generic chunk of data that is not interpreted by the EAP layer. Theabsence of a GCA would preferably be indicated by a GCA length indicatorset to zero.

To provide backward compatibility the GCA should preferably be includedin the EAP packets in a way that is transparent to pass-through EAPauthenticators. A pass-through EAP authenticator is an EAP authenticator(residing in an NAS; typically a WLAN AP or an access router) thatrelays (almost all) EAP packets between the MN and a back-end EAPauthentication server (a AAA server). It is stated in [12] that thepass-through behavior of an EAP authenticator is to relay EAP packetsbased on the EAP layer header, i.e. the Code, Identifier and Lengthfields in the beginning of the EAP packets. This implies that thedesired transparency (and hence backward compatibility) could possiblybe achieved if the GCA is placed after the EAP layer header (i.e. afterthe Code, Identifier and Length fields).

However, an EAP authenticator normally also has to check the Type field(following the EAP layer header) of EAP Response packets in order toidentify EAP Identity Response packets, from which the NAI that isneeded for the AAA routing is extracted. When the EAP authenticatoridentifies an EAP Identity Response packet, it extracts the NAI from theType-Data field following the Type field. Hence, placing the GCAimmediately after the EAP layer header (in a manner that is transparentto the EAP authenticator) is only possible in EAP Request packets.Therefore, it would normally be preferable to arrange the GCA after theType field or even after the (possibly NULL-terminated) Type-Data field.

Placing the GCA immediately after the Type field would enable the use ofthe GCA in all EAP Response packets but EAP Identity Response packets.The use of the GCA in EAP Identity Response packets would be prohibited,because from these packets the EAP authenticator needs to extract theNAI from the Type-Data field, which a legacy EAP authenticator wouldexpect to find immediately after the Type field. This may be arestriction for the GCA usage considering that EAP normally has ratherfew round trips. Possibly, the GCA could be placed after aNULL-terminated Type-Data field in the EAP Identity Response packet,while keeping its position after the Type field in other EAP packets.

It would often be desirable with a GCA position that can be usedconsistently in all EAP packets. From the above discussion it seems thata position in which the GCA could be placed in all EAP packets in abackward-compatible manner is at the end of the packet, more or less asa trailer. However, this GCA location may cause problems for those EAPpackets that do not have explicit length indicators for the Type-Dataparameter(s), but relies on the Length field in the EAP layer header. Inthese packets it would not be able to distinguish the GCA from theType-Data field.

To solve this problem the order of the GCA length indicator, the GCArecipient indicator and the GCA payload should be reversed such that theGCA length indicator appears last. Thus, when placing the GCA at the endof an EAP packet, the last two octets of the EAP packet (whose length isindicated by the Length field in the EAP layer header) would always bethe GCA length indicator. Unless the GCA length indicator is zero, theGCA recipient indicator would appear before the GCA length indicator andthe GCA payload (whose size is determined from the GCA length indicator)would be located before the GCA recipient indicator. Through thisprinciple it would always be possible to identify the GCA in an EAPpacket and to distinguish the GCA from the Type-Data field. Still theuse of the GCA would be transparent for a pass-through EAPauthenticator.

Backward compatibility with this GCA solution further requires that theEAP authenticator does not try to extract information from the EAPRequest/Response packets (except the EAP layer header and the NAI) andthat it accepts that the Length field in the Success/Failure packetsindicates a value is greater than 4.

An alternative way to cope with the backward compatibility problem is touse EAP GCA Test Request/Response packets (i.e. new EAP packets withnewly defined values of the Type field) to determine whether the MNsupports the GCA.

Before or after the initial EAP Identity Request/Response packetexchange an EAP authenticator supporting the GCA would send an EAP GCATest Request packet (i.e. an EAP Request packet with a dedicated Typevalue) to the MN (the EAP peer state machine in [13] indicates that bothalternative sending times would be feasible). If the MN supports theGCA, it responds with an EAP GCA Test Response packet. Otherwise the MNinterprets the EAP GCA Test Request packet as a request to use anunknown EAP method and therefore the MN responds with an EAP Nak packet.From the response from the MN the EAP authenticator can determinewhether the MN supports the GCA.

An MN supporting GCA can determine whether the EAP authenticatorsupports the GCA from the presence or absence of the EAP GCA TestRequest packet. If an EAP GCA Test Request packet is received whenexpected (i.e. before or after the EAP Identity Request/Responseexchange), the EAP authenticator supports the GCA. Otherwise it doesnot.

If both the MN and the EAP authenticator support the GCA, it is placedafter the EAP layer header in all subsequent EAP packets (with theoriginal order of the GCA components). Otherwise, the GCA may still beincluded in the EAP packets that allow it to be included in abackward-compatible manner (as described above).

There are some limitations to the described alternative way of dealingwith the backward compatibility problem. Firstly, one MN-EAPauthenticator roundtrip is wasted. Moreover, if the EAP GCA TestRequest/Response packets are exchanged after the initial EAP IdentityRequest/Response packet exchange, the GCA cannot be used in the EAPIdentity Response packet. This embodiment may also require that the EAPauthenticator (probably the NAS) uses a modified version of EAP, such asEAPv2. Accordingly, although other alternatives are possible, thepreferred way of arranging the GCA in EAP packets would typically be asa trailer at the end of the packet with the GCA length indicator last,after the GCA payload and the GCA recipient indicator.

If the number of EAP round trips is not enough for the data that isexchanged in the GCAs, the AAAh may consider increasing the number ofEAP round trips through EAP Notification Request/Response exchanges forthe purpose of conveying the GCA.

Another variant is actually to introduce the GCA in an EAP method on themethod layer of the EAP protocol stack. If the GCA is made EAP methodspecific, the GCA does not introduce any backward compatibility problem,since it will then normally be a part of the Type-Data field.

Exemplary Signaling Flows for EAP/HMIPv6

FIG. 7 illustrates an exemplary EAP/HMIPv6 (Diameter) signaling flow forthe case when MAP is located in the home network.

The AAA Client requests MN authentication using EAP (Request Identity),and the MN responds with EAP (Response Identity).

The MN response is sent to the AAAh via the AAA infrastructure. The AAAhdetermines from the identity of the MN and based on operator policy thatEAP/HMIPv6 methodology is appropriate for authentication andauthorization of the MN (i.e. the AAAh knows the capabilities of theMN). The AAAh sends an indication of the suggested EAP methodology (e.g.EAP/HMIPv6) along with a challenge to the MN via the AAA infrastructure.The indication of EAP methodology or scheme may be implemented byassigning a new EAP Type number for the extended EAP scheme (e.g.EAP/HMIPv6). In this way, the mobile node will know which EAP schemethat the AAAh is proposing. Alternatively, a specially formattedchallenge is sent to the mobile node, which recognizes that thechallenge indicates a given EAP scheme.

The MN desires to bootstrap HMIPv6, and replies to the AAAh suggestionand challenge with a challenge response as well as appropriate EAPattributes (TLVs) that convey a request to be assigned an appropriateMAP along with the necessary information for security association withthe assigned MAP. In this process, the MN is also able to bootstrapMIPv6 if this has not yet been carried out previously. The MN responseis sent to the AAAh via the AAA infrastructure. Although the MAPassignment request may in fact be implicit, it is normally recommendableto make use of an explicit MAP assignment request. For cases where themobile node is already aware of the MAP address and may e.g. simply berenewing the security association with the MAP, there will be no MAPassignment request, but only re-authentication and/or reauthorization.

The AAAh validates the MN's challenge response and if successful thismeans that the MN is authentic, and the AAAh then proceeds to processthe MN's other requests.

First, the AAAh selects a MAP in the home network, and sends the MAP anenhanced EAP (note that this is a separate EAP session than the onealready ongoing between the MN and the AAAh) message comprising e.g. thesecurity key(s), and the MAP responds to the AAAh, preferably byproviding information, if required or otherwise appropriate, forfinalizing the security association with the MN. For example, for IPSecsecurity associations it may be necessary to make use of EAP attributessuch as the IPSec Protocol, IPSec Crypto, IPSec Key Lifetime EAP TLVattributes defined in Table I above.

In this and the following illustrative examples, it is assumed that themobile node (MN) and the AAAh have a common shared secret. This couldfor example be a symmetric key shared between the identity moduleinstalled in the mobile node and the home network operator. The identitymodule can be any tamper-resistant identity module known to the art,including standard SIM cards used in GSM (Global System for MobileCommunications) mobile telephones, Universal SIM (USIM), WAP (WirelessApplication Protocol) SIM, also known as WIM, ISIM (IP MultimediaSubsystem Identity Module) and, more generally, UICC (UniversalIntegrated Circuit Card) modules. For the MN-MAP (MN-HA) securityassociation, a seed or nonce can be conveyed by the MN to the AAAh (orthe other way around, i.e. the seed is originated by the AAAh andconveyed to the MN) from which the AAAh can create the MN-MAP (MN-HA)security key(s) based on the shared secret. The mobile node is able togenerate the same security key(s) by itself since it originated theseed/nonce (or receives the seed from the AAAh) and also has the sharedsecret. Alternatively, the AAAh may itself generate the securityinformation and securely transfer it to the relevant nodes.

Secondly, if MIPv6 bootstrapping is requested, the AAAh proceeds toservice this MIPv6 bootstrapping request by selecting a HA using anotherenhanced EAP session, and the HA responds to the AAAh by providinginformation necessary to create the security association with the MN.Optionally, it is possible to piggyback “MAP binding updates” as well as“HA binding updates” in the authentication and authorization exchanges.This means that the HMIPv6 binding is integrated in the same round tripas the MN-MAP security association (only the LCoA is required in thebinding update from the mobile). For this case, the HMIPv6 RCoA obtainedby the AAAh in the first operation with the MAP is automatically MIPv6binding updated with the HA in the second operation.

After the AAAh has communicated with the MAP and HA as described above,the AAAh sends the authorization (and/or configuration) information suchas MAP address, RCoA, HA address, MN home address, and securityassociation information along with an authentication success indicationback to the MN via extended EAP. The extra last round trip of exchangesin FIG. 7 is to ensure that the EAP protocol is concluded smoothlyaccording to the current EAP protocol specification.

FIG. 8 illustrates an exemplary EAP/HMIPv6 (Diameter) signaling flow forthe case when MAP is located in the visited network.

The AAA Client requests MN authentication using EAP (Request Identity),and the MN responds with EAP (Response Identity).

The MN response is sent to the AAAh via the AAA infrastructure. The AAAhdetermines from the identity of the MN and based on operator policy thatEAP/HMIPv6 methodology is appropriate for authentication andauthorization of the MN (i.e. the AAAh knows the capabilities of theMN). The AAAh sends and indication of the suggested EAP methodology(i.e. EAP/HMIPv6) along with a challenge to the MN via the AAAinfrastructure.

The MN desires to bootstrap HMIPv6, and replies to the AAAh suggestionand challenge with a challenge response as well as appropriate EAPattributes (e.g. TLVs) that convey a request to be assigned anappropriate MAP along with the necessary details for securityassociation with the assigned MAP. The MN is also in the process able tobootstrap MIPv6 if this has not yet been carried out previously. The MNresponse is sent to the AAAh via the AAA infrastructure.

The AAAh validates the MN's challenge response and if successful thismeans that the MN is authentic, and the AAAh proceeds to process theMN's other requests.

First, the AAAh forwards a request for MAP in the visited network to theappropriate AAAv, this is preferably done via a Diameter applicationwhich for simplicity has been called Diameter HMIPv6 Application. Thereason for this is that the visited operator's policy has to be takeninto account in the selection of MAP in the visited network, and theAAAv thus needs to be able to see the transaction (with EAP theexchanges are end-to-end and this is not possible). The AAAv selects aMAP in the visited network, and forwards the Diameter HMIPv6 Applicationmessage containing e.g. security key(s) to the MAP. The MAP responds tothe AAAh via the AAAv, preferably by providing information, if requiredor otherwise appropriate, for finalizing the security association withthe MN. Secondly, the AAAh proceeds to service the MIPv6 bootstrappingrequest, if such a request is present, by selecting a HA using anotherenhanced EAP session, and the HA responds to the AAAh by providinginformation necessary to create the security association with the MN.Note that it is possible to piggyback “MAP binding updates” as well as“HA binding updates” in the authentication and authorization exchanges.For this case, the HMIPv6 RCoA obtained by the AAAh in the firstoperation with the MAP is automatically MIPv6 binding updated with theHA in the second operation.

After the AAAh has communicated with the MAP and HA as described above,the AAAh sends the authorization (and/or configuration) information suchas MAP address, RCoA, HA address, MN home address and securityassociation information along with an authentication success indicationback to the MN via extended EAP. The extra last round trip of exchangesin FIG. 8 is to ensure that the extended EAP protocol is concludedsmoothly according to the current EAP protocol specification.

Although some of the detailed exemplary embodiments have primarily beendiscussed with reference to the current EAP version, it should beunderstood that the invention very well is applicable onto other EAPversions, such as EAPv2, as well as other authentication protocolsextended or configured in the described manner. EAP is merely an exampleof a possible implementation, and the invention is generally not limitedthereto and may alternatively involve non-EAP schemes.

AAA Framework Protocol Application for HMIPv6

In another exemplary embodiment, a new AAA framework protocolapplication, here exemplified by a Diameter Application adapted forHMIPv6 (referred to as “Diameter HMIPv6 Application”), is created thatcarries HMIPv6-related information facilitating for example discovery ofMAP, dynamic allocation of MAP, dynamic allocation of RCoA, distributionof security keys between MN and MAP, and/or possible piggyback of HMIPv6mobility procedures. Although Diameter is referred to in the following,it should be understood that Radius or other similar AAA frameworkprotocol can be used as a basis for a new or extended HMIPv6application.

If desired, both HMIPv6 and MIPv6 authentication and/or authorizationcan be integrated in the same AAA framework protocol application. Thiscan be accomplished by employing the Diameter MIPv6 Applicationdescribed in [3], and in addition defining new HMIP-specific commandcodes, AVPs, and/or flags. By including the command codes, AVPs, andflags of the Diameter MIPv6 Application as part of the Diameter HMIPv6Application, it will be possible to accommodate simultaneous executionsof both MIPv6 and HMIPv6 authentication and/or authorization in a singletraversal which enables shorter setup times. It would also be possibleto execute only HMIPv6 authentication and/or authorization without theMIPv6 counterpart and vice versa, depending on the particular need ofthe MN at a specific instance. This allows a single application, theDiameter HMIPv6 Application, to be flexibly used on various use casescenarios.

Furthermore, piggyback of HMIPv6 mobility procedures in Diameter HMIPv6Application allows possible shortening of overall setup times byoptimizing authentication, authorization, and mobility in a commonprocedure.

Diameter HMIPv6 Application Details

In the following, exemplary Diameter HMIPv6 Application details areprovided to show examples of the overall flow and viability of concept.Preferably, new HMIP-specific command codes, AVPs, and/or flags aredefined that would carry information that facilitate for examplediscovery of MAP, dynamic allocation of MAP, dynamic allocation of RCoA,distribution of security keys between MN and MAP, and/or possiblepiggyback of HMIPv6 mobility procedures. The command codes, AVPs, andflags of the Diameter MIPv6 Application [3] may optionally be includedas part of the Diameter HMIPv6 Application.

An exemplary summary matrix of Diameter HMIPv6 Application Command Codesand AVPs is given below in Table 2: Diameter HMIPv6 Application CommandCodes and AVP's Source Destination Purpose Comment HMIPv6 specificcommand codes: MAP-HMIPv6-Request Command (MAR) AAAh MAP exchange ofHMIP AVP's MAP in home AAAh MAP via AAAv exchange of HMIP AVP's MAP invisited MAP-HMIPv6-Answer Command (MAA) MAP AAAh exchange of HMIP AVP'sMAP in home MAP AAAh via AAAv exchange of HMIP AVP's MAP in visitedHMIPv6 specific AVP's: HMIP-Binding-Update AVP HMIP Binding Updatemessage sent by MN to MAP HMIP-Binding-acknowledgement AVP HMIP BindingAcknowledgement sent by MAP to MN RCoA AVP RCoA MAP Address AVP MAPaddress HMIPv6-Feature-Vector AVP MAP-Requested Flag requests for adynamic MAP assignment MAP-MN Pre-shared Key Generation Nonce AVP seedfor MN-MAP key MAP-MN Pre-shared Key AVP assign MN-MAP key MAP IKE KeyIDAVP assign IKE KeyID MAP-MN IPSec SPI AVP assign SPI MAP-MN IPSecProtocol AVP assign IPSec Protocol MAP-MN IPSec Crypto AVP assign IPSecCrypto MAP-MN IPSec Key Lifetime AVP assign IPSec Key Lifetime ExistingDiameter MIPv6 Application command codes: AA-Registration-RequestCommand (ARR) AAA Client AAAh (via AAAv) AA-Registration-Answer Command(ARA) AAAh AAA Client (via AAAv) Home-Agent-MIPv6-Request Command (HOR)AAAh HA Home-Agent-MIPv6-Answer Command (HOA) HA AAAh Existing DiameterMIPv6 Application AVP's: MIP-Binding-Update AVP Mobile IP Binding Updatemessage sent by MN to HA MIP-Binding-acknowledgement AVP Mobile IPBinding Acknowledgement sent by HA to MN MIPv6-Mobile-Node-Address AVPthe Mobile Node's Home Address MIPv6-Home-Agent-Address AVP the MobileNode's Home Agent Address MIPv6-Feature-Vector AVP Home-Agent-RequestedFlag requests for a dynamic home agent assignment

For additional information, the Internet draft [5] defines Command Codesand AVPs necessary to carry EAP packets between a Network Access Server(NAS) and a back-end authentication server.

Exemplary Signaling Flows for Diameter HMIPv6 Application

FIG. 9 illustrates an exemplary Diameter HMIPv6 Application signalingflow for the case when the MAP is located in the home network.

The AAA Client issues a challenge to the MN to be authenticated, forexample via protocols such as the Internet Control Message Protocol(ICMP), PANA and so forth. The MN responds with a challenge responsealong with HMIPv6 and possibly also MIPv6 bootstrapping requests.

The AAA Client understands HMIPv6 and MIPv6 bootstrapping requests, andforwards the MN response to the AAAh via the AAA infrastructure usingDiameter HMIPv6 Application command code (ARR). In the process, the AAAClient also includes the challenge to allow the AAAh to verify theauthenticity of the MN.

The AAAh validates the MN's challenge response and if successful thismeans that the MN is authentic, and the AAAh then proceeds to processthe MN's other requests.

First, the AAAh selects a MAP in the home network, and sends the MAP theappropriate Diameter HMIPv6 Application command code (MAR) containinge.g. security keys, and the MAP responds to the AAAh, preferably byproviding information, if required or otherwise appropriate, forfinalizing the security association with the MN via command code (MAA).Secondly, if MIPv6 bootstrapping is requested, the AAAh proceeds toservice the MIPv6 bootstrapping request by selecting a HA using DiameterHMIPv6 Application command code (HOR), and the HA responds to the AAAhby providing information necessary to create the security associationwith the MN via command code (HOA). Note that it is possible topiggyback “MAP binding updates” as well as “HA binding updates” in theauthentication and authorization exchanges. For this case, the HMIPv6RCoA obtained by the AAAh in the first operation with the MAP isautomatically MIPv6 binding updated with the HA in the second operation.

After the AAAh has communicated with the MAP and HA as described above,the AAAh sends the authorization (and/or configuration) information suchas MAP address, RCoA, HA address, MN home address and securityassociation information along with an authentication success indicationback to the MN via Diameter HMIPv6 Application command code (ARA) andfor example ICMP, PANA and so forth.

FIG. 10 illustrates an exemplary Diameter HMIPv6 Application signalingflow for the case when the MAP is located in the visited network.

The AAA Client issues a challenge to the MN to be authenticated, forexample via ICMP or PANA. The MN responds with a challenge responsealong with HMIPv6 and possibly also MIPv6 bootstrapping requests.

The AAA Client understands HMIPv6 and MIPv6 bootstrapping requests, andforwards the MN response to the AAAh via the AAA infrastructure usingDiameter HMIPv6 Application command code (ARR). In the process, the AAAClient also includes the challenge to allow the AAAh to verify theauthenticity of the MN.

The AAAh validates the MN's challenge response and if successful thismeans that the MN is authentic, and the AAAh then proceeds to processthe MN's other requests.

First, the AAAh forwards a request for MAP in the visited network to theappropriate AAAv, this is done via Diameter HMIPv6 Application commandcode (MAR). The AAAv selects a MAP in the visited network, and forwardsthe MAP the command code (MAR) which includes for example the securitykeys and the MAP responds to the AAAh via the AAAv, preferably byproviding information, if required or otherwise appropriate, forfinalizing the security association with the MN using command code(MAA). Secondly, if requested, the AAAh proceeds to service the MIPv6bootstrapping request by selecting a HA using Diameter HMIPv6Application command code (HOR), and the HA responds to the AAAh byproviding information necessary to create the security association withthe MN via command code (HOA). Note that it is possible to piggyback“MAP binding updates” as well as “HA binding updates” in theauthentication and authorization exchanges. For this case, the HMIPv6RCoA obtained by the AAAh in the first operation with the MAP isautomatically MIPv6 binding updated with the HA in the second operation.

After the AAAh has communicated with the MAP and HA as described above,the AAAh sends the authorization (and/or configuration) information suchas MAP address, RCoA, HA address, MN home address, and securityassociation information along with an authentication success indicationback to the MN via Diameter HMIPv6 Application command code (ARA) and aprotocol such as ICMP or PANA.

Summarizing some of the above aspects, it can be seen that the relianceon the AAA infrastructure offers a number of possibilities forbootstrapping the HMIPv6 service. For example, it is possible to providean extension to a general authentication protocol such as current orfuture EAP versions carried over the AAA infrastructure and/or toenhance an AAA framework protocol application such as Diameter andRADIUS applications.

FIG. 11 is a schematic flow diagram of a basic example of a method forsupporting HMIPv6 service for a mobile node. In this example, theinformation transfer and actions indicated in steps S1-S4 relate toauthentication of the mobile node (S1), establishment of an MN-MAPsecurity association (S2), HMIPv6 configuration (S3) and HMIPv6 binding(S4). The steps S2-S3 are commonly referred to as the authorizationphase. The steps S1-S4 may, if desired, be executed more or less inparallel, for example piggy-backing the HMIPv6 binding in the same roundtrip as the HMIPv6 security association procedure, to allow shorteningof the overall setup times. In step S1, information is transferred overthe AAA infrastructure for authenticating the mobile node at the homenetwork side. In step S2, HMIPv6-related information is transferred toimmediately establish, or to enable future establishment of a securityassociation between the MN and MAP. In step S3, additional HMIPv6configuration is performed, for example by transferring configurationparameters to the mobile node for suitable storage therein. In step S4,the mobile node sends a binding update and a HMIPv6 binding isestablished in the MAP.

Among other application areas, the invention is applicable to all accessnetworks such as WLAN, CDMA2000, WCDMA and so forth, where HMIPv6 andoptionally also MIPv6 can be used, including technologies such as AAAand IPv6 mobility, systems such as CMS11, WCDMA and GSM systems,sub-systems such as service/application subsystems and terminals, andproducts such as AAA servers, Home Agent Servers and terminal nodes.

As an alternative to the above described example procedures for MN-HAkey distribution, a mechanism similar to the current 3GPP2 solution inconjunction with the IKE framework can be used to distribute dynamicpre-shared keys for MN and HA.

The embodiments described above are merely given as examples, and itshould be understood that the present invention is not limited thereto.Further modifications, changes and improvements which retain the basicunderlying principles disclosed and claimed herein are within the scopeof the invention.

REFERENCES

-   [1] Mobility Support in IPv6, D. Johnson, C. Perkins, J. Arkko, Jun.    30, 2003, <draft-ietf-mobileip-ipv6-24.txt>.-   [2] Hierarchical Mobile IPv6 mobility management (HMIPv6), Hesham    Soliman, Claude Castelluccia, Karim El-Malki, Ludovic Bellier, June,    2003, <draft-ietf-mobileip-hmipv6-08.txt>.-   [3] Diameter Mobile IPv6 Application, Stefano M. Faccin, Franck Le,    Basavaraj Patil, Charles E. Perkins, April 2003,    <draft-1e-aaa-diameter-mobileipv6-03.txt>.-   [4] MIPv6 Authorization and Configuration based on EAP, G.    Giaretta, I. Guardini, E. Demaria, February 2004,    <draft-giaretta-mip6-authorization-eap-00.txt>.-   [5] Diameter Extensible Authentication Protocol (EAP)    Application, P. Eronen, T. Hiller, G. Zorn, Feb. 16, 2004,    <draft-ietf-aaa-eap-04.txt>.-   [6] PPP Extensible Authentication Protocol (EAP), RFC2284, L.    Blunk, J. Vollbrecht, March 1998.-   [7] IEEE Standard 802.1X, Local and metropolitan area    networks—Port-Based Network Access Control.-   [8] Internet Security Association and Key Management Protocol    (ISAKMP), RFC2408, D. Maughan, M. Schertler, M. Schneider, J.    Turner, November 1998.-   [9] Diameter Mobile IPv4 Application, P. Calhoun, T. Johansson, C.    Perkins, 2003, <draft-ietf-aaa-diameter-mobileip-14.txt>.-   [10] Remote Authentication Dial In User Service (RADIUS)—RFC2865, C.    Rigney, S. Willens, A. Rubens, W. Simpson, June 2000.-   [11] RADIUS Extensions—RFC2869, C. Rigney, W. Willats, P. Calhoun,    June 2000.-   [12] Extensible Authentication Protocol (EAP)—RFC2284, L. Blunk, J.    Vollbrecht, B. Aboba, J. Carlson, H. Levkowetz, September 2003,    <draft-ietf-eap-rfc2284bis-06.txt>.-   [13] State Machines for EAP Peer and Authenticator, J.    Vollbrecht, P. Eronen, N. Petroni, Y. Ohba, October    2003<draft-ietf-eap-statemachine-01.pdf>.

1. A method of supporting Hierarchical Mobile IP version 6 (HMIPv6)service for a mobile node, characterized by using an AAA infrastructureto bootstrap the HMIPv6 service including: said AAA infrastructureassigning an appropriate Mobility Anchor Point (MAP) to the mobile nodefor the HMIPv6 service; and transferring HMIPv6-related informationrequired for authenticating and authorizing the mobile node for theHMIPv6 service with the assigned MAP over said AAA infrastructure. 2.The method of claim 1, characterized in that an AAA server of said AAAinfrastructure assigns an appropriate MAP to the mobile node for theHMIPv6 service.
 3. The method of claim 2, characterized in that themobile node is roaming in a visited network, and an AAA visited networkserver (AAAv) assigns a MAP in the visited network to the mobile node.4. The method of claim 3, characterized in that the AAAv assigns a MAPbased on a policy of the visited network operator.
 5. The method ofclaim 3, characterized in that the mobile node sends a MAP assignmentrequest to an AAA home network server (AAAh) over the AAAinfrastructure, and the AAAh forwards the MAP assignment request to theAAA visited network server (AAAv), and the AAA home network servergenerates credential-related data for security association between themobile node and the assigned MAP, said credential-related data beingtransferred from the AAAh to the MAP via the AAAv, the AAAh generatesinformation for finalizing the security association or the MAP respondswith information for finalizing the security association to the AAAh viathe AAAv, and the AAAh sends HMIPv6 authorization information includingMAP assignment information, binding address information and securityassociation information to the mobile node over the AAA infrastructure.6. The method of claim 2, characterized in that an AAA home networkserver (AAAh) assigns a MAP in the home network to the mobile node. 7.The method of claim 6, characterized in that the AAA home network server(AAAh) generates credential-related data for security associationbetween the mobile node and the assigned MAP and sends saidcredential-related data to the MAP, the AAAh generates information forfinalizing the security association or the MAP responds with informationfor finalizing the security association to the AAAh, and the AAAh sendsHMIPv6 authorization information including MAP assignment information,binding address information and security association information to themobile node over the AAA infrastructure.
 8. The method of claim 1,characterized in that an AAA infrastructure component of the homenetwork generates credential-related data for security associationbetween the mobile node and the assigned MAP and sends saidcredential-related data to the MAP, the AAA infrastructure home networkcomponent generates information for finalizing the security associationor the MAP responds with information for finalizing the securityassociation to the AAA infrastructure home network component, whichsends HMIPv6 authorization information to the mobile node over the AAAinfrastructure.
 9. The method of claim 1, characterized in that saidHMIPv6-related information comprises HMIPv6 authentication,authorization and configuration information.
 10. The method of claim 1,characterized by transferring HMIPv6-related information over said AAAinfrastructure for establishing a HMIPv6 security association betweenthe mobile node and the assigned MAP.
 11. The method of claim 10,characterized by transferring HMIPv6-related information over said AAAinfrastructure for establishing a HMIPv6 binding for the mobile node.12. The method of claim 11, characterized by transferring HMIPv6-relatedinformation for HMIPv6 binding in the same round trip as HMIPv6-relatedinformation for HMIPv6 security association.
 13. The method of claim 1,characterized in that the mobile node is roaming in a visited network,and HMIPv6-related authentication and authorization information istransferred between the mobile node and an AAA home network server(AAAh) within an authentication protocol in an end-to-end proceduretransparent to the visited network.
 14. The method of claim 13,characterized in that said authentication protocol is an extendedauthentication protocol.
 15. The method of claim 14, characterized inthat said extended authentication protocol is an extended ExtensibleAuthentication Protocol (EAP), and said HMIPv6-related information isincorporated as additional data in the EAP protocol stack.
 16. Themethod of claim 15, characterized in that said HMIPv6-relatedinformation is transferred as EAP attributes in the EAP method layer ofthe EAP protocol stack.
 17. The method of claim 15, characterized inthat said HMIPv6-related information is transferred in a genericcontainer in the EAP protocol stack.
 18. The method of claim 15,characterized in that the extended EAP protocol is carried by PANA, PPPor IEEE 802.1X between the mobile node and an AAA client in the visitednetwork, and by Diameter or Radius within the AAA infrastructure. 19.The method of claim 1, characterized in that the assigned MAP is locatedin the home network of the mobile node, and HMIPv6-related informationis transferred between the mobile node and an AAA home network server(AAAh) within an authentication protocol, and HMIPv6-related informationis transferred between the AAAh and the assigned MAP in a separatesession of the authentication protocol or within an AAA frameworkprotocol application.
 20. The method of claim 13, characterized in thatthe assigned MAP is located in the visited network, and HMIPv6-relatedinformation is transferred between the mobile node and the AAA homenetwork server (AAAh) within said authentication protocol, andHMIPv6-related information is transferred between the AAAh and theassigned MAP in the visited network within an AAA framework protocolapplication.
 21. The method of claim 20, characterized in that said AAAframework protocol application is a Diameter or Radius applicationadapted for HMIPv6.
 22. The method of claim 1, characterized in thatsaid HMIPv6-related information is transferred in an AAA frameworkprotocol application over said AAA infrastructure.
 23. The method ofclaim 22, characterized in that said AAA framework protocol applicationis a Diameter or Radius application adapted for HMIPv6.
 24. The methodof claim 1, characterized by simultaneously accommodating HMIPv6 andMIPv6 authentication and authorization in the same round trip over saidAAA infrastructure.
 25. A system for supporting Hierarchical Mobile IPversion 6 (HMIPv6) service for a mobile node, characterized by: an AAAinfrastructure component operable for assigning an appropriate MobilityAnchor Point (MAP) to the mobile node for the HMIPv6 service; and meansfor transferring HMIPv6-related information required for authenticatingand authorizing the mobile node for the HMIPv6 service with the assignedMAP over said AAA infrastructure.
 26. The system of claim 25,characterized in that said AAA infrastructure component is an AAA serverthat is operable for assigning an appropriate MAP to the mobile node forthe HMIPv6 service.
 27. The system of claim 26, characterized in thatthe mobile node is roaming in a visited network, and an AAA visitednetwork server (AAAv) is operable for assigning a MAP in the visitednetwork to the mobile node.
 28. The system of claim 27, characterized inthat the AAAv is operable for assigning a MAP based on a policy of thevisited network operator.
 29. The system of claim 27, characterized inthat an AAA home network server (AAAh) comprises: means for forwarding aMAP assignment request received over said AAA infrastructure from themobile node to the AAA visited network server (AAAv); means forgenerating credential-related data for security association between themobile node and the assigned MAP; means for sending saidcredential-related data to the assigned MAP via the AAAv; means forreceiving, from the MAP via the AAAv, information for finalizing thesecurity association and binding address information; and means forsending HMIPv6 authorization information including MAP assignmentinformation, binding address information and security associationinformation to the mobile node over the AAA infrastructure.
 30. Thesystem of claim 26, characterized in that an AAA home network server(AAAh) is operable for assigning a MAP in the home network to the mobilenode.
 31. The system of claim 30, characterized in that the AAA homenetwork server (AAAh) comprises: means for generating credential-relateddata for security association between the mobile node and the assignedMAP; means for sending said credential-related data to the assigned MAP;means for receiving information from the MAP for finalizing the securityassociation and binding address information; means for sending HMIPv6authorization information including MAP assignment information, bindingaddress information and security association information to the mobilenode over the AAA infrastructure.
 32. The system of claim 25,characterized in that an AAA infrastructure component of the homenetwork comprises: means for generating credential-related data forsecurity association between the mobile node and the assigned MAP; andmeans for sending said credential-related data to the assigned MAP;means for receiving information from the MAP for finalizing the securityassociation; and means for sending HMIPv6 authorization information tothe mobile node over the AAA infrastructure.
 33. The system of claim 25,characterized in that said HMIPv6-related information comprises HMIPv6authentication, authorization and configuration information.
 34. Thesystem of claim 25, characterized by means for transferringHMIPv6-related information over said AAA infrastructure for establishinga HMIPv6 security association between the mobile node and the assignedMAP.
 35. The system of claim 34, characterized by means for transferringHMIPv6-related information over said AAA infrastructure for establishinga HMIPv6 binding for the mobile node.
 36. The system of claim 35,characterized by means for transferring HMIPv6-related information forHMIPv6 binding in the same round trip as HMIPv6-related information forHMIPv6 security association.
 37. The system of claim 25, characterizedin that the mobile node is roaming in a visited network, andHMIPv6-related authentication and authorization information istransferred between the mobile node and an AAA home network server(AAAh) within an authentication protocol in an end-to-end proceduretransparent to the visited network.
 38. The system of claim 37,characterized in that said authentication protocol is an extendedauthentication protocol.
 39. The system of claim 38, characterized inthat said extended authentication protocol is an extended ExtensibleAuthentication Protocol (EAP), and said HMIPv6-related information isincorporated as additional data in the EAP protocol stack.
 40. Thesystem of claim 39, characterized in that said HMIPv6-relatedinformation is transferred as EAP attributes in the EAP method layer ofthe EAP protocol stack.
 41. The system of claim 39, characterized inthat said HMIPv6-related information is transferred in a genericcontainer in the EAP protocol stack.
 42. The system of claim 39,characterized in that the extended EAP protocol is carried by PANA, PPPor IEEE 802.1X between the mobile node and an AAA client in the visitednetwork, and by Diameter or Radius within the AAA infrastructure. 43.The system of claim 25, characterized in that the assigned MAP islocated in the home network, and HMIPv6-related information istransferred between the mobile node and an AAA home network server(AAAh) within an authentication protocol, and HMIPv6-related informationis transferred between the AAAh and the MAP in a separate session of theauthentication protocol or within an AAA framework protocol application.44. The system of claim 37, characterized in that the assigned MAP islocated in the visited network, and HMIPv6-related information istransferred between the mobile node and an AAA home network server(AAAh) within said authentication protocol, and HMIPv6-relatedinformation is transferred between the AAAh and the assigned MAP in thevisited network within an AAA framework protocol application.
 45. Thesystem of claim 44, characterized in that said AAA framework protocolapplication is a Diameter or Radius application adapted for HMIPv6. 46.The system of claim 25, characterized in that said HMIPv6-relatedinformation is transferred in an AAA framework protocol application oversaid AAA infrastructure.
 47. The system of claim 46, characterized inthat said AAA framework protocol application is a Diameter or Radiusapplication adapted for HMIPv6.
 48. The system of claim 25,characterized by means for simultaneously accommodating HMIPv6 and MIPv6authentication and authorization in the same round trip over said AAAinfrastructure.
 49. An AAA server for supporting Hierarchical Mobile IPversion 6 (HMIPv6) service for a mobile node, characterized by means forassigning an appropriate Mobility Anchor Point (MAP) to the mobile nodefor the HMIPv6 service.
 50. The AAA server of claim 49, characterized inthat the mobile node is roaming in a visited network, and said AAAserver is an AAA visited network server (AAAv) operable for assigning aMAP in the visited network.
 51. The AAA server of claim 50,characterized in that said AAAv is operable for assigning a MAP based ona policy of the visited network operator.
 52. The AAA server of claim49, characterized in that said AAA server is an AAA home network server(AAAh) operable for assigning a MAP in the home network of the mobilenode.
 53. The AAA server of claim 49, characterized in that said MAPassigning means operates in response to a MAP assignment requestinitiated from the mobile node.
 54. The AAA server of claim 49,characterized in that said MAP assigning means is operable forperforming network-initiated MAP assignment.
 55. An AAA home networkserver (AAAh) for supporting Hierarchical Mobile IP version 6 (HMIPv6)service for a mobile node, characterized by: means for generatingcredential-related data for security association between the mobile nodeand a Mobility Anchor Point (MAP) assigned by an AAA infrastructurecomponent; and means for sending said credential-related data to theassigned MAP; means for receiving information from the MAP forfinalizing the security association; and means for sending HMIPv6authorization information including security association information tothe mobile node.
 56. The AAA home network server of claim 55,characterized in that said mobile node is roaming in a visited network,and said means for sending HMIPv6 authorization information is operablefor sending the information over an AAA infrastructure linking thevisited network with the home network of the mobile node.
 57. The AAAhome network server of claim 56, characterized in that said AAA homenetwork server is configured for receiving, from the assigned MAP,information for finalizing the security association as well as bindingaddress information, and said means for sending HMIPv6 authorizationinformation over the AAA infrastructure is configured for sending HMIPv6authorization information including MAP assignment information, bindingaddress information and security association information to the mobilenode.
 58. A system for supporting Hierarchical Mobile IP version 6(HMIPv6) service for a mobile node, characterized by means fortransferring HMIPv6-related authentication and authorization informationin an Extensible Authentication Protocol (EAP) between the mobile nodeand an AAA home network server over an AAA infrastructure forauthenticating and authorizing the mobile node for HMIPv6 service, saidHMIPv6-related information being incorporated as additional data in theEAP protocol stack.